-
Notifications
You must be signed in to change notification settings - Fork 502
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
services/horizon/internal/actions: Add /order_book ingestion endpoint #1761
services/horizon/internal/actions: Add /order_book ingestion endpoint #1761
Conversation
cd6c791
to
2e80047
Compare
Codecov Report
@@ Coverage Diff @@
## release-horizon-v0.22.0 #1761 +/- ##
==========================================================
Coverage ? 45.31%
==========================================================
Files ? 393
Lines ? 26853
Branches ? 0
==========================================================
Hits ? 12168
Misses ? 13443
Partials ? 1242
Continue to review full report at Codecov.
|
7bc46ba
to
4f2034f
Compare
4f2034f
to
f611559
Compare
@abuiles please ignore this PR while you are on vacation :) . I added you so you can skim through the PR when you get back |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good but requires some changes. Haven't checked tests yet.
Amount: amount.String(total), | ||
}) | ||
|
||
delete(amountForPrice, offerPrice) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't we use offer.Price
here? offerPrice
can be inverted.
delete(amountForPrice, offerPrice) | |
delete(amountForPrice, offer.Price) |
response.Bids = offersToPriceLevels( | ||
handler.OrderBookGraph.FindOffers(buying, selling, limit), | ||
true, | ||
) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's possible that the first call to OrderBookGraph.FindOffers
will get offers for ledger X
and the second one for ledger X+1
. I think we need to make a new function (GetOrderbook
) that calls two FindOffers
in a locked section of code.
} | ||
|
||
response.Asks = offersToPriceLevels( | ||
handler.OrderBookGraph.FindOffers(selling, buying, limit), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think limit
determines the max number of price levels not offers in the old code. If the limit is, say, 10
and there are more than 10
offers at a the first price level the result will be invalid. We need to create GetOrderbook
on order book graph anyway (check the other comment) so should be easy to fix.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
limit
determines the max number of price levels in the new code as well
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right, sorry!
@bartekn I pushed a commit which addressed your PR comments |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM except overflow issue. Will do a last check after fix is ready.
|
||
amountForPrice := map[xdr.Price]xdr.Int64{} | ||
for _, offer := range offers { | ||
amountForPrice[offer.Price] += offer.Amount |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This reminded me of a similar issue from the past: #436. Basically issuers can send MAX_INT64
to any of it's trustors. If two of them with MAX_INT64
create offers with the same price this can overflow. Looks like we may need to use math/big
here and then convert numbers using amount.IntStringToAmount
.
It seems that existing /order_book
endpoint deals with it because postgres handles overflows properly (so doesn't overflow).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bartekn great catch, I've pushed a commit which fixes this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks, looks great!
PR Checklist
PR Structure
otherwise).
services/friendbot
, orall
ordoc
if the changes are broad or impact manypackages.
Thoroughness
.md
files, etc... affected by this change). Take a look in the
docs
folder for a given service,like this one.
Release planning
needed with deprecations, added features, breaking changes, and DB schema changes.
semver, or if it's mainly a patch change. The PR is targeted at the next
release branch if it's not a patch change.
Summary
Implement
/order_book
implement using the in memory order book graph populated by the experimental ingestion system.Fixes #1705
Goal and scope
The current
/order_book
endpoint queries Stellar Core's database to find all the bids and asks for a given trading pair. The experimental ingestion system provides us with an in memory order book graph. This allows us to implement the/order_book
endpoint without querying Stellar Core's database at all.The goal of the experimental ingestion system is that we reduce the coupling between horizon and Stellar Core's database. Implementing the
/order_book
endpoint using the in memory order book brings us one step closer towards that goal.Note that I've still kept the old
/order_book
handler which queries Stellar Core's database. The old handler will still be used by horizon instances that choose not to run the experimental ingestion system.Summary of changes
/order_book
endpoint which can be used by both the JSON and SSE handlers